1. Field
The present specification relates generally to client-server systems, and more particularly to the problem of socket handling for VoIP and collaborative systems.
2. Description of the Related Art
VoIP and collaborative systems currently use standard commercial operating systems, such as VxWorks, in order to leverage economies of scale. VxWorks is a single-process operating system (derived from the general-purpose BSD 4.3 of UNIX systems), where all concurrent threads (or tasks) share a global memory space. Originally, each UNIX process is assumed to have a small number (e.g., 64) of file descriptors (also known as sockets) but VxWorks extends it to a larger set (e.g., 2048).
Standard commercial operating systems supply socket-handling facilities whose design is based on assumptions that are not valid for VoIP and collaborative systems. For example, VxWorks utilizes a polling system that reaches its maximum efficiency with extensive use of relatively few sockets, whereas VoIP systems typically have a large number of peripheral devices each of which needs to be supplied with socket services that, even under heavy load conditions, result in relatively light socket usage.
Typically, I/O multiplexing is performed over a large number of sockets using industry standard (i.e. BSD 4.3-compatible) socket services such as “select” or “poll”. However, the use of standard socket services results in high computing overhead and poor scalability. Specifically, on each polling task, the operating system (OS) kernel must search across many sockets to find the relatively few ones with active events, and it must do so for each of several applications that are active at one time.
In general, there are three basic models or methods for socket I/O multiplexing. A first method is to spawn a task (i.e., a thread) for each TCP connection wherein each task handles one socket I/O. However, this method works only for small and simple systems. It cannot be applied to a system handling a large number of sockets because it results in a large number of tasks being created in the system, causing high memory cost and excessive system processing overhead.
A second method is to use a single task to control (i.e. multiplex) a group of sockets. This task continually makes a select call (i.e. select( )), with a predetermined non-zero timeout value, which allows the select( ) call to wait until an I/O event arrives at any given socket before the waiting time expires.
The third method, referred to herein as the “polling model”, is similar to the second method except that it periodically polls the set of sockets, wherein each poll call (i.e. poll( )) returns immediately. By polling the sockets, the computational overhead is reduced when compared to the second method by making system calls less frequently and collecting more I/O ready socket events with each call. One problem, however, with the “polling model” method is that it introduces a response delay to the I/O events.
It should be noted that VxWorks does not support poll( ). However, a person of ordinary skill in the art will appreciate that a “select” call having zero timeout value is logically equivalent to poll( ). Both select and poll are theoretically of the same computational complexity (although poll may have a small factor of improvement over select in some operating systems). Since all such systems nonetheless require sequential checking of the list of N sockets, for the sake of convenience this specification occasionally uses the terms “select” and “poll” interchangeably.
Heuristic methods have been used to find the best value of polling interval, or polling window (PW), for a particular system. Usually, PW is related to a set of system attributes, such as: maximum number of IP phones supported; maximum traffic throughput (Calls-Per-Hour); minimum I/O delay, etc.
An increase in N results in an increase in PW. However, an increased N is also associated with an increased traffic requirement, which in turn requires a smaller PW. Reducing the PW value increases the traffic throughput (or reduces the I/O delay); but increases the CPU consumption. For a given system with limited CPU resources, the choice of PW ends up being a tradeoff of system attributes to control I/O multiplexing overhead within an acceptable range.
As an example of the foregoing, the MN3300 system manufactured by Mitel Networks Corporation is a distributed TCP/IP client-server system, where a single Integrated Communication Platform (ICP) controller (or a cluster of interconnected ICPs), plays a server role to support up to N=1400 IP phone clients. Each IP phone establishes a TCP socket connection with the ICP for signaling purposes. However, the ICP controller typically must perform I/O multiplexing over a very large number of TCP sockets to communicate with the IP phones. The computational cost of this I/O multiplexing is directly proportional to N (total number of sockets), causing high overhead of O(N) computational time as well as scalability problems when N is large. In an effort to address the scalability problem, in some commercial implementations of the MN3300 system the VxWorks kernel has been re-compiled for select service to support 2048, 4096, and 8192 file descriptors and thereby accommodate an increased number of IP phones.
In the prior art MN3300 system, one task is responsible for polling TCP sockets every PW=40 milliseconds. Thus, for an MN3300 system designed for N=1400 phones and about 8000 CPH traffic throughput under a saturated level of CPU usage, reducing PW from 40 milliseconds to 20 milliseconds can cause some iPBX service outage. To support a larger system, say N=3000, the MN3300 system needs to increase its CPU capacity.